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I. INTRODUCTION 



A. BACKGROUND AND BRIEF PROBLEM STATEMENT 

Autonomous vehicles can go where humans cannot or do not want to go. 
These robots are capable of receiving initial input, moving to another location and 
executing a mission, and returning with the requested results or data. In addition to 
perfonning labor-intensive or repetitive tasks, these vehicles can perfonn their jobs 
faster and with greater precision than humans, and can also proceed into hostile or 
contaminated environments. 

For the last thirty years, remotely-operated vehicles (ROVs) have attempted to 
fill these needs. The last decade’s tremendous advances in computer and systems 
engineering have produced powerful, reliable, and inexpensive ROVs capable of a 
wide variety of tasks. These vehicles are commonplace in the oil-drilling, salvage, 
and ocean engineering industries, and they are extending the reach of 
oceanographers with lengthy missions that produce high-resolution data from great 
depths. The armed forces of several countries use ROVs for battlefield 
reconnaissance and long-range targeting, and military ROV research continues. 

(Bane and Ferguson, 1987.) 

Although they have become extremely useful to the militaiy, ROVs still 
require operator supervision and are incapable of independent operations. Tliis 
handicap greatly reduces their ability to execute complicated, covert missions in 
hostile territory where an unknown and dangerous environment requires impromptu 
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planning to handle unforseen situations. Since ROV systems have proven their 
military usefulness, future designs must make these combat vehicles truly 
autonomous. 

The U.S. Navy has identified a number of tasks that can be performed by 
Autonomous Underwater Vehicles (AUVs), and the Defense Advanced Research 
Projects Agency (DARPA) strongly supports AUV research (Robinson, 1986; 
Eisenstadt, 1987). Researchers are applying ROV technology to design powerful 
AUV systems with high endurance, small profiles, and extended range. However, 
the greatest challenges lie in producing artificial intelligence (AI) systems to support 
mission execution, vehicle perception and navigation, and contingency planning. 

The Naval Postgraduate School is developing an experimental AUV to address 
these military requirements. Part of this project is the design of simulators that will 
reduce the time and expense of implementing various AUV subsystems while also 
permitting efforts to proceed along several simultaneous approaches. Previous 
simulator research (MacPherson, 1988) has shown that graphics workstations provide 
a useful way to simulate a realistic environment for conducting AUV operations. 
This approach permits the prompt development and thorough testing of AI software 
and will be used to test code for the NPS AUV while also developing the next 
generation of software. 

This thesis improves on the original research by expanding and upgrading its 
systems. In addition, a new simulator has been developed to generate a "laboratory 
environment" for testing several AUV planning, navigation, and control subsystems. 
This new simulator wUl also be used to examine different AUV hydrodynamic 
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models and to test maneuvering systems in conjunction with different sensor 
configurations. These proven subsystems will be integrated with the AUV mission 
planner to develop full-scale proposed missions before operational testing of the 
actual vehicle. 

B. THESIS ORGANIZATION 

Chapter II reviews previous work on ROV and AUV systems and examines 
system architecture and programming language issues. The use of modem computer 
workstations for vehicle simulations is discussed and an example is included. 

Chapter III presents a detailed problem statement for this thesis and describes 
the mathematical model for the dynamics of both vehicles. The autopilot and 
logical control levels are discussed and the features of the two vehicle models and 
their environments are compared. The simulation facilities are also described and 
contrasted. 

A detailed description of the simulator’s design and operation is presented in 
Chapter IV. This includes an examination of the autopilot, the dynamics of both 
vehicles, the operation of the inter-computer communications code, and a user’s 
manual. The overall software system design is described to show how actual 
vehicle changes or improvements can be added to the simulator to keep it as 
realistic as possible. 

The simulator’s operation is examined in Chapter V. This chapter explains 
the various missions that can be run on the simulator and their results. These 
results are summarized in Chapter VI and are used as a basis for proposed 
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extensions and improvements. This chapter also explains the contributions this 
research has made to the development of autonomous vehicles. 
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n. SURVEY OF PREVIOUS WORK 



A. INTRODUCTION 

Remotely-operated vehicles (ROVs) have been in operation since the early 
1950s and autonomous vehicle research began in the early 1960s. Although the 
early ROVs were limited in range, notoriously difficult to control, and mechanically 
unreliable, autonomous vehicles were even more severely restricted by available 
technology. Through the early 1970s, manned vehicles were required for most tasks 
while maturing ROV technology developed useful ranges, better controls, and 
reliability. However, although ROV use began to grow, technological handicaps 
caused autonomous vehicle research to die out by the end of die 1960s. (Brady et 
al., 1984.) 

The 1980s have produced dramatic improvements in processor capability and 
speed, component miniaturization, signal processing, sensor resolution, and high- 
energy-density power supplies. These rapid advances have been integrated with 
ROV operations and have rekindled autonomous vehicle research for a variety of 
nrulitary and industrial uses. ROV applications are widespread in the military and 
have become commonplace in many industries. In 1986, the Defense Advanced 
Research Projects Agency (DARPA) AUV Study Committee identified over seventy 
military AUV missions (Bane and Ferguson, 1987) while additional groups described 
many other military and industrial uses for AUVs (Robinson, 1986). U.S. Navy 
ship designers are also accommodating AUV technology— the Sea Wolf {SSN-21) 
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class of attack submarines wUl have larger-diameter torpedo tubes capable of 
deploying AUVs for anti-submarine warfare or other uses (Baker, 1989). 

This chapter surveys current ROV uses and then shows how this teclinology 
and operational experience has been applied to AUV research. Different AUV 
programs are described and their research issues are discussed. The last section of 
this chapter discusses the use of computer simulations for the research and testing 
of vehicle dynamics and controls. 

B. REMOTELY-OPERATED VEHICLE (ROV) TECHNOLOGY 

MacPherson (1988) describes several military ROV programs under 
development or in operation. The U.S. Navy’s Remotely-piloted Vehicle (RPV) for 
airborne ocean surveillance and the Israeli Armed Forces battlefield RPVs have seen 
several years of operating experience; in some cases their utility has been 
demonstrated in actual combat (Steele, 1988). 

In contrast to the military’s recent ROV experience, industrial ROVs have 
undergone explosive growth in the last five years. Researchers from industry and 
academia have formed many groups, and several annual symposia display a broad 
range of ROVs for a variety of applications and budgets (ROV ’89, 1989). These 
products are frequently used in the offshore oil-drilling and underwater construction 
fields where the danger or expense of using human workers is prohibitive. Another 
well-publicized operation was the use of the Alvin and its Jason Jr. ROV to locate 
and explore the Titanic (WHOI, 1986; Yoerger et al., 1986). In addition to the 
salvage industry, ROVs have gained widespread acceptance in oceanographic 
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research. The remainder of this section will discuss several of these programs and 
their ROVs. 

1 . Sea Ferret 

The Underwater Resources, Inc. Sea Ferret (or "miniROVer") is a small, 
low-cost ROV used in tunnels and penstocks to perform corrosion surveys and 
welding inspections. This vehicle operates in the tunnels of hydroelectric plants or 
water-treatment facilities to observe valve or gateway operations, perform damage 
assessments, make repairs, and perform non-destructive weld testing. Although it 
appears to be an expensive "high tech" application for "low-tech" facilities, the Sea 
Ferret has saved millions of dollars in maintenance, troubleshooting, and emergency 
repair costs while reducing the manpower and risks associated with this type of 
work. (Underwater Resources, 1989.) 

2. Sea Owl 

The Sea Owl is a small industrial ROV from Scandinavian Underwater 
Technologies (SUTEC) that incorporates many of the latest design concepts in the 
ROV industry. Instead of a torpedo-shaped body-of-revolution hull or an open- 
frame cage to house its components, the Sea Owl uses a hydrofoil twin-cylinder hull 
that the operator "flies" through the water. While earlier ROVs used a single 
propulsor, the Sea Owl’s seven thrusters give the vehicle maneuvering agility and 
mechanical redundancy. With its five-foot length, two-foot beam, three-knot speed, 
and 1500-foot depth limit, this ROV is a low-cost system used by oil platforms and 
salvage operations. The "300" version has many different near-shore applications 
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and the larger 500 model is a more expensive platfonn suitable for open-ocean 
salvage or exploration. (SUTEC, 1989.) 

3. Sea Twin 

The Sea Twin (also by SUTEC) is a follow-on to the Sea Owl design 
that adds extra features for a different environment. With its larger hull and 
additional thruster, this ROV is nearly fifty percent bigger and has twice the 
displacement of the Sea Owl. The greater size and thrust is used for higher power 
and increased stability in rapid currents where smaller ROVs are unable to operate. 
In addition to its vehicle improvements, the Sea Owl system also uses fiber-optic 
signal transmission technology to produce a smaller, low-drag tether cable with a 
much wider signal bandwidth. This advanced cable makes the ROV capable of 
simultaneously handling several different types of sensors or of transmitting real- 
time high-resolution video. (SUTEC, 1989.) 

4. EGA 

This French corporation is one of the world’s largest ROV producers and 
is noted for their low-cost designs of highly adaptable vehicles. Their Pope ROV is 
a general-purpose vehicle used for near-shore or coastal operations, with a variant 
for open-ocean work. Another ROV, the PAP 104, is designed for high-resolution 
searches and charting applications; its manipulators also possess a high degree of 
manual dexterity that make this system very effective in underwater demolition. 

The PAP 104 Mk5 is a military version used for mine warfare. As of early 1989, 
ECA has sold over 325 ROVs to many corporations and to the navies of eleven 
European and Asian countries. (ECA, 1989.) 
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5. Gemini 6000 



Eastport International, Inc., has made significant advances in the use of 
ROVs for open-ocean search and salvage. Their Gemini 6000 ROV is the size of a 
small auto with a 9,000 pound displacement and two seven-function hydraulic 
manipulators. The vehicle uses several photographic systems and a fiber-optic link 
to transmit real-time high-resolution color video as well as record 35mm pictures 
and stereo photographs. 

In 1985, an earlier version of the Gemini 6000 located and recovered 
most of the remains of a Boeing 747 aircraft from a depth of 7000 feet. In 1986, 
this ROV mapped the crash site of the space shuttle Challenger, and the vehicle 
augmented diver’s salvage efforts by retrieving many of the spacecraft’s fragments 
from deeper waters. (SUBNOTES, 1989a.) 

In February 1989, the Gemini 6000 recovered an aircraft flight recorder 
from a new record salvage depth of 14,800 feet. This was also the first use of an 
ROV in an aircraft accident investigation; it involved a survey of more than 200 
objects in an area of over a square rrule. During 345 hours of bottom time, the 
Gemini 6000 transmitted many hours of high-resolution video, took over 2400 35mm 
photos, and recorded over 300 stereoscopic photos. (Sea Technology, 1989.) 

6. Oceanographic Research 

The Monterey Bay Aquarium Research Institute (MBARI) is a non-profit 
research institute founded in 1988 to study the oceanography of Monterey Bay on 
the central California coast. The bay is actually a deep underwater canyon that 
starts less than a mile offshore and reaches depths in excess of 5000 feet within ten 
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miles of the coast. The canyon’s close proximity to land and its unusual features, 
the rich diversity in the bay’s ecology, and a large number of oceanographic 
research facilities in the area have all combined to give MBARI a number of 
opportunities to conduct deep-ocean research. 

To support this work, MBARI uses an open-frame ROV from 
International Submarine Engineering of Canada. The vehicle, also about the size of 
a small car, has four thrusters, seven camera systems, and a seven-function 
manipulator. It is capable of operating in depths up to 6000 feet and has already 
used its deep-ocean collecting, surveying, and photographic abilities to help explain 
severed uruesolved research questions. (SUBNOTES, 1989b.) 

C. AUTONOMOUS UNDERWATER VEfflCLE TECHNOLOGY 

The technology used in ROVs is directly applicable to AUVs since both types 
of vehicles require sophisticated controls, rapid maneuverability, extended ranges, 
high-resolution sensors, and high-capacity signal processing. However, the most 
significant AUV technological development has been the large-scale introduction of 
cheap, high-performance computer processors. The wide availability of the Intel 
80386 and Motorola 68030 series of processors, as weU as RISC and VME 
arcliitectures, has moved AUV projects out of the lab and into industrial 
development (SUBNOTES, 1989). Research has produced ROVs that routinely 
operate in the harsh ocean environment; the next challenge is to make autonomous 
vehicles that are as reliable as ROVs and that will perform tasks which ROVs 
cannot. This section will survey industrial, academic, and military AUV research. 
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1. XP-21 



Applied Remote Technology, Inc. (ART), has developed a test hull for 
its prototype AUV. The XP-21 has a 16-foot torpedo-shaped hull 21 inches in 
diameter with a displacement of 1700 pounds; it can accommodate a 700-pound 
payload of up to eight cubic feet. This vehicle can submerge to 2000 feet with a 
six-hour endurance at six knots. ART is using the XP-21 to verify the performance 
of hardware and software for navigation, guidance, control, and communications 
subsystems that will be incorporated into a larger AUV. (SUBNOTES, 1988; ART, 
1989.) 

2. PTEROA 

The University of Tokyo has developed a small AUV for independent 
sea floor mapping. The PTEROA is roughly five feet long with a three-foot beam 
and a maximum speed of 3.5 knots on two small tlu'usters. Tlie designers 
deliberately simplified the AUV’s control and propulsion systems to minimize power 
demands and to reduce computing overhead. The vehicle submerges with ballast to 
allow it to descend in a slow glide to the sea floor. Once near the bottom, the 
PTEROA drops its ballast and proceeds along its search pattern, recording data while 
using its sonar to navigate along bottom contours. (Tamaki, 1989.) 

3. EAVE East 

One of the most advanced operational AUV research programs is 
conducted by the University of New Hampshire Marine Systems Engineering 
Laboratory. The Experimental Autonomous Vehicle (EAVE) is an op>en-frame, 
highly-maneuverable submersible with two models for use as system development 
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test beds. (This program is called "HAVE East" to distinguish it from the San 
Diego Naval Ocean Systems Center’s "EAVE West" tethered vehicle.) 

Where feasible, the EAVE East uses redundant sensors to verify its 
inputs for critical reliability in a hostile operating environment. A pressure 
transducer and a fathometer measure the vehicle’s depth while a five-beam sonar is 
used for obstacle detection and avoidance. The EAVE’s navigation module first 
fixes its position with both long- and short-baseline acoustic systems and then 
verifies the AUV’s heading with an on-board magnetic compass. (Jalbert, 1987.) 

The EAVE’s computer architecture achieves an innovative integration of 
several different hardware and software systems. A VME bus coordinates eight 
Motorola 68000-series processors with 4 Mbytes of RAM and an 800 Mbyte optical 
disk. Several sub-processors handle the tasks of external I/O, rapid memory access, 
and memory caching without lowering execution speed. A real-time operating 
system supports the AUV’s Portable Common LISP Subset (PCLS) software. This 
operating system is used to divide the EAVE’s resources into a high-level and a 
low-level hierarchical architecture for mission planning and vehicle control. 

The high-level component of the system uses five of its processors to 
update and evaluate the environmental knowledge base, to replan the mission if 
unexpected events or casualties occur, and to supervise the lower-level system 
components. These processes run in a loop with approximately a 100- second cycle 
time. The low-level portion uses the remaining three processors to analyze sensor 
data, control vehicle motion, and collect additional sensor inputs approximately once 
per second. (Shevenell, 1987.) 
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The vehicle’s hierarchical control structure closely mimics the division of 
responsibility used in human chains of command. The mission-level planner is at 
the top of this hierarchy and accepts human user input for the mission’s objectives 
and priorities. The planner develops a launch-to-recovery mission profile that 
examines energy requirements, time limits, and risk factors to evaluate a number of 
alternatives and select the optimal mission plan. Instructions are then sent to lower- 
level planners that deal only with the next specific sub-task to be performed. As 
the mission proceeds, the top-level planner updates its status and replans the mission 
to accommodate unexpected events. This structure produces the intelligent, adaptive 
behavior that autonomous vehicles require for executing complex missions in a 
hostile environment. (Blidberg and Chapell, 1986.) 

4. DARPA Funding 

Encouraged by the rapid development of industrial and academic AUV 
programs, the Defense Advanced Research Projects Agency (DARPA) has 
committed up to $100 million to support AUV projects with military applications 
(Eisenstadt, 1987). This includes a recent $23.9 million contract issued to Draper 
Laboratories for the development of two AUVs to serve as test vehicles for various 
U.S. Navy missions. These AUVs will carry instrumented systems and will execute 
mission packages developed by Martin Marietta (ROV News, 1989). 

D. CONTROL SYSTEM SOFTWARE ARCHITECTURES 

The most significant difference between AUVs and ROVs is the substitution 
of an artificial intelligence (AI) control system for the human operator. Although 
these control systems can execute instructions and process data much more quickly 
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and more reliably than any human, they frequently lack the flexibility and response 
time needed for a rapid reaction to unexpected events or casualties. Much of 
today’s AUV research is concentrating on the development of computer 
architectures, languages, and operating systems that can provide this flexibility while 
retaining speed and reliability. Two aspects of these issues are discussed below. 

1. Distributed versus hierarchical control 

Many different real-time control systems attempt to improve their overall 
speed by having data pass through as few processors as possible. Ideally, this 
system would use some sort of memory to receive and store incoming data while a 
master processor would examine all data and immediately dispatch it to the 
appropriate subsystem for further processing. After manipulating the data, all co- 
processors would report thek results as additional data, which would then be re- 
dispatched to the next appropriate co-processor, and so on. 

These processing schemes have been grouped under the heading of 
"blackboard systems" to describe the way data is posted at a central location to 
await pickup for analysis. A blackboard system can use object-oriented 
programming to share information between expert subsystems without the time- 
consuming overhead of data transfer, and one implementation of this scheme is 
being used to support the development of an AUV control system. (Doty and 
Wachter, 1986.) 

Although blackboard architectures can minimize unnecessary data 
transfer, current implementations have difficulty acliieving satisfactory response times 
or flexibility. Each expert system devotes a significant overhead (hardware 
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interrupts) to "checking the blackboard" for arriving data, and an attempt to assign 
higher priorities to time-sensitive data events frequently generates unacceptable 
additional overhead. Another blackboard drawback is the method by which data is 
identified for the appropriate expert system. Emergencies, errors, and unexpected 
results will be posted but may never be "picked up" by an expert subsystem if the 
data does not fit into an identifiable category. An exception-handling mechanism 
can notify the system of these problems but is usually unable to correct them, so 
the machine’s processing gradually slows down or abruptly crashes. 

A hierarchical system imitates human chains of command by dividing 
large projects into progressively smaller tasks that are handled at lower levels. The 
lower processing levels accept results from even lower levels, operate on the 
information, and pass their results up to a higher level. The higher levels will act 
on this input, pass orders and data back down to the lower level, and report their 
results to progressively higher levels of control. In this way, an object-oriented 
system can manipulate small objects that are nested in larger objects; the lower 
objects usually can communicate only by passing their data through their parent 
object. 

A hierarchical architecture ensures that all data is eventually handled by 
some process or object. However, data-sharing between adjacent modules is 
restricted so the same information exchange requires more handling than a 
blackboard system. In addition, the system’s central knowledge base is available to 
fewer processors so more data transfers are needed to get information to the 
appropriate location. Although hierarchical systems use fewer interrupts for I/O 
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polling, lower-level processors can block the execution of a higher processor; the 
higher level may be idle until data is passed up to it. Finally, while a hierarchical 
system will handle errors and unanticipated events more easily, the division of 
responsibilities is crucial to prevent higher-level processors from being overloaded 
by routine tasks and exception-handling. 

The deficiencies of each individual architecture tend to make their 
separate implementations unwieldy, slow, and unreliable. However, systems that 
combine elements of the two schemes often achieve significant improvements with 
few side effects. These "hybrid" architectures can use faster blackboard concepts to 
reduce data transfers by making information more available while their hierarchical 
structures ensure that exception-handling is successfully completed. (Doty and 
Wachter, 1986; MacPherson, 1988.) 

2. Language Alternatives 
a. LISP versus Prolog 

Two of today’s most popular artificial intelligence languages are 
LISP and Prolog. Conceived in the late 1950s, LISP is one of the earliest AI 
languages and has had over three decades of refinement and standardization. Its 
modular code, list-oriented structure, and low-level operators give it a speed that 
justifies its recognition as the "assembly language" of AI. On the other hand, 
Prolog is a relatively new and extremely powerful language with a rule-based 
structure that makes it very useful for developing the collections of rules known as 
"expert systems." 



16 



Each language has several deficiencies. Compared to Prolog, LISP 
is faster but much harder to read. Its recursive routines make programming counter- 
intuitive and debugging very difficult. Its many dialects have recently been 
standardized but this standardization is slow and still incomplete. Although LISP 
executes very quickly, its low-level design also makes it difficult to implement 
higher-level AI abstractions. In particular, LISP lacks any built-in inferencing 
mechanism. 

Since Prolog is a high-level language, it is easier to design high- 
level structures. However, the language executes more slowly than LISP and Prolog 
requires large amounts of memory for its back-tracking execution. Although Prolog 
simplifies the construction and maintenance of large rule-based systems, it can be 
difficult to thoroughly test these system’s permutations and subsequently correct 
unintended side-effects. Continued improvements to Prolog and its associated 
debuggers will improve this language’s facilities. 

The top-level controller of an AUV will require a system with the 
speed advantages of LISP yet the power and flexibility of Prolog. The construction 
of such a system will depend heavily on a large library of reliable mission- 
execution subroutines using portable code that can function as "building blocks" for 
the next generation of missions and systems. 

b. Expert System Shells: KEE versus ART 

Expert systems have been developed to make up for LISP’s 
inferencing deficiencies; these systems are one example of an attempt to combine 
the best features of LISP and Prolog. KEE (Knowledge Engineering Environment) 
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and ART (Automated Reasoning Tool) are examples of a class of software called 
"expert system shells". Programmers use these software tools to buUd knowledge- 
based expert systems and to apply them to large, complex problems. These systems 
are especially useful in AI applications where the problems may be ill-defined or so 
complex that the software system must mimic the decision-making processes of 
human experts. 

The KEE shell contains a number of features for manipulating a 
knowledge base and its corresponding set of rules. Part of this system is a 
graphical user-interface module and a set of object-oriented programming routines; 
these two frames provide an intuitive and powerful means of organizing and 
executing LISP functions. (KEE User’s Manual, 1986.) 

The ART shell also uses a rule-based scheme to operate on its 
exp>ert system. Four different types of rules can be used to describe and manipulate 
a knowledge base. A powerful ART "inference engine" wUl compile and execute 
this collection of rules and data, repeatedly drawing conclusions from the knowledge 
base and applying these conclusions to generate more data for the knowledge base. 
This scheme continues until a specific goal is achieved. (ART Reference Manual, 
1986.) 

Both shells use a proprietary structured language to implement their 
rule-based systems, and both shells are able to incorporate LISP functions into their 
execution for the control of other systems. Although the lack of a standard mle- 
based language (such as Prolog) is a drawback, the AUV simulator does not use 
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any niles to execute its missions. Instead, the simulator uses its shell to organize 
and to efficiently execute the many routines that make up the expert system. 



Since these shells are applicable to many situations involving 
complicated path-planning or scheduling problems, they are both suitable for the 
mission level of tlie AUV simulator. Compared to KEE, the ART shell has a much 
more powerful rule-based language, but its interfaces are not intuitive and can 
present problems for inexperienced users. Since the simulator uses no mles, 

ART’s user interface is a significant disadvantage. KEE has been chosen since it 
provides the simplest user interface— one that requires little system knowledge for 
mission execution, and one that can be quickly manipulated with a mouse. 
c. Ada 

When it was faced with rapidly-rising software development and 
maintenance costs and reduced software portability, the U.S. Department of Defense 
(DoD) sponsored the development of a high-level programming language that would 
be suitable for a wide range of applications. The Ada programming language filled 
these specifications and is building a large library of portable subroutines that will 
reduce software development, maintenance, and compatibility costs. The DOD has 
subsequently decreed that Ada will be the programming language for all mission- 
critical U.S. military projects and has trademaiked the language to enforce its 
standardization. 

Many of the guidance, navigation, and control subsystems of an 
AUV or ROV can be programmed in Ada. However, an AUV’s top-level planner 
is a specialized AI construct requiring a language with the features and power of 
LISP or Prolog. Ada is not yet suitable for this application. 
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E. COMPUTER SIMULATION OF VEHICLE DYNAMICS AND CONTROL 



In the last ten years, the rapid deployment of ROVs has validated vehicle and 
sensor designs. ROVs are readily available for uses in an ever-increasing variety of 
environments and applications, and their control systems and signal-processing 
capabilities continue to improve. Recent ROV advances have largely been 
technological updates of existing concepts, and industry’s experience is lowering the 
subsequent research and development costs. Many improvements are made by 
inexpensive alterations of "off-the-shelf components instead of through new designs, 
and the industry will mature as vehicles become cheaper and more available to the 
common user. 

AUV design is not so advanced. While ROVs can cheaply use rapid 
prototyping and testing techniques, AUVs are still quite complicated and costly. 

The operational testing process subjects these expensive vehicles to harsh and 
unpredictable environments where the logistics are difficult and some AUV losses 
are unavoidable. While there is no substitute for operational experience, most of 
the AUV’s engineering problems have been solved while learning how to operate 
ROVs. The last step is the development of a high-level mission planner that can be 
simply and cheaply tested without expiensive logistics and unaffordable losses. 

One solution to this problem is computer simulations. Through the use of 
vehicle simulators, AI mission planners can be developed in the laboratory and can 
receive data inputs from artificial (computer-generated) sources. The planner’s 
outputs can be used to drive a simulator whose actions can be observed and 
interpreted to evaluate the effectiveness of the planner without having to risk the 
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vehicle. The same powerful computer systems that have revived AUV research can 
thus be used for rapid AUV prototyping and low-risk initial testing. 

One of these systems was developed and tested in 1986. A Westinghouse 
research team, as part of a preliminary AUV design project, programmed a test 
system for an AUV mission planner and navigator. The inputs and outputs for this 
planner are handled by a simple graphics simulator that provides the AUV with 
information about the surrounding environment and then revises its display to show 
actions ordered by the AUV mission planner. The simulator generates and updates 
a picture that shows the planner setting up a mission, the navigator determining a 
path, and the AUV executing these orders while reaching its objectives and avoiding 
obstacles. (Schweizer and Oravec, 1986.) 

F. SUMMARY 

This chapter presents a survey of previous research and accomplishments that 
are relevant to this thesis. A listing of representarive current ROV technology is 
followed by a discussion of AUV research and issues. Different system 
architectures and programming languages are presented and will be evaluated in 
following chapters. This chapter concludes with a brief discussion and an example 
of the advantages of modem computer workstations for dynamic system simulation. 
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ni. DETAILED PROBLEM STATEMENT 



A. INTRODUCTION 

This thesis provides a real-time graphical simulation of a proposed AUV and 
facilitates the development and testing of various control algorithms. The simulator 
is part of a Naval Postgraduate School (NPS) research project that will design, 
build, and test a series of Autonomous Underwater Vehicles. 

B. VEHICLE CHARACTERISTICS 

The NPS Autonomous Underwater Vehicle is modelled after the Swimmer 
Delivery Vehicle (SDV) used for the delivery and extraction of U.S. Navy Special 
Warfare Teams. The actual NPS Model 2 AUV will resemble the SDV so the 
simulator’s vehicle dynamics have been scaled to the dimensions of the AUV 
currently under construction. 

The simulator’s controller carries out AUV operations by directing its output to 
either of two graphical representations. The original graphics display is a simplified 
vehicle that models complex AUV missions in the open-ocean environment. The 
second graphics display uses a more sophisticated SDV hydrodynamic model in a 
small "test pool" to evaluate various AUV configurations and to develop the actual 
control algorithms that will be used by the NPS Model 2 AUV. 
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1. The Original Vehicle 

The first vehicle simulation (MacPherson, 1988) permits mission execution 
without requiring a detailed implementation of AUV dynamics. The simulator 
represents a small manned vehicle with a control panel and a "through the 
periscope" display similar to that of the U.S. Navy’s Sturgeon class attack 
submarine. The vehicle has a single screw and mdder and maintains continuous 
neutral buoyancy. Aft, stemplanes impart a hull pitch angle for large depth changes 
while forward-mounted bowplanes provide more precise depth control without 
generating a pitch angle. Although users can manually operate the AUV, the 
vehicle is normally under autopilot control. 

The original dynamic model consists of a simple point-mass approximation 
governed by one acceleration equation, two rate equations, and one attitude equation. 
The vehicle’s location and orientation is described by applying these equations at a 
10-Hz rate and by setting the autopilot’s control surface positions according to depth 
or course error. AUV speed is chosen by the autopilot and is limited by battery 
charge or by the onset of cavitation. Acceleration is fixed at 1 knot/sec^ while 
depth and azimuth rates depend on a combination of speed and control surface 
angle. The vehicle’s pitch angle is assigned a steady-state value determined by the 
AUV’s speed and stemplane angle. 

Although the AUV displays rigid behavior and little inertial delay, no 
attempt was made to model actual submarine dynamics since these would have little 
impact on the large-scale decisions implemented by the mission controller. This 
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model is a simple and effective way to display the actions and results generated by 
mission execution algorithms. 

2. The NFS AUV 

The second simulation is based on the Swimmer Delivery Vehicle’s 
dynamics and on preliminary NFS model hydrodynamic test data (MacDonald, 

1989). The hull shape is a flattened cylinder with a rounded bow and a tapered 
stem; the AUV maneuvers with bow planes, stem planes, twin rudders, and twin 
screws. The dynamics model uses a vehicle mass of 12,000 pounds at neutral 
buoyancy with a length of 17 feet, a beam of five feet, and a height of 2.5 feet. 
The NFS Model 2 AUV is equipped with two vertical and two horizontal thrusters, 
so the simulator image also shows these thrusters. (See Figure 3.1.) 

The AUV’s position, orientation, and velocity is determined by calculating 
hydrodynamic drag forces and Euler angle rates and then updating these parameters 
at a 30-Hz rate. The AUV is displayed from an external point of view instead of 
the earlier "through the periscope" perspective. The simulation algorithm is a 
considerable improvement over the original model since the AUV exhibits realistic 
acceleration and inertial behavior. 

The original version of this simulator (Schwartz, 1989) was designed to 
evaluate AUV hydrodynamic coefficients and to examine the resulting vehicle 
dynamics under a variety of speeds and pitch angles. The simulator relies on the 
user’s manipulation of the vehicle’s control surfaces and its speed; there is no 
autopilot controller. 
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Figure 3.1 NFS AUV Simulator 
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The second generation of this program uses a simple autopilot depth- or 
course-error calculation to set control surface positions for maneuvers. Autopilot 
orders create control surface angles which in turn act on the AUV hydrodynamic 
model to generate hull pitch angles and resulting changes in depth or course. 
Although this first-order controller produces abrupt and non-linear control surface 
behavior, the NFS AUV design team is developing an advanced control system. 

The simulator’s code structure will allow this advanced controller algorithm to be 
installed between the autopilot and the hydrodynamic model. 

Although the hydrodynamic model has a length of 17 feet, the vehicle 
displayed on the simulation graphics workstation is scaled to a length of five feet. 
This inconsistency between the hydrodynamic model and the visual vehicle makes 
the simulator’s NFS AUV appear to maneuver differently from the characteristics of 
a 17-foot model. This effect does not affect the simulator’s mission planning; the 
inconsistency will be corrected when the hydrodynamic model of the NFS AUV is 
incorporated into the simulator. 

C. ENVIRONMENT 

The ocean environment for the original AUV simulator is described in detail in 
MacFherson (1988). The simulation begins with the AUV at periscope deptli in a 
sector of water five nautical miles on a side. Tlie sea floor of this model is a 
submerged cone with an exposed island (the cone’s vertex) near the center of the 
sector. In addition to the island and its shoals, the AUV must also contend with a 
number of surface contacts— military vessels, merchant ships, and buoys. The large 



26 



body of water and its congested environment provide a realistic test of the AUV’s 
mission control and guidance software. 

The water environment for the NFS AUV sunulator is modelled after a 
proposed test site for the actual vehicle. The simulation displays a "swimming 
pool" (120 feet by 60 feet by eight feet deep) containing a number of submerged 
cylindrical obstacles. The simulator’s AUV and test pool are scaled to the actual 
sizes of the NFS AUV and its test site, although the hydrodynamic model is not 
scaled to this environment. (See earlier discussion in B.2.) The test pool is a 
much simpler environment tlian that of the earlier simulation and is intended to give 
the AUV design team a realistic way to test various algorithms for mission control, 
guidance, and vehicle control before integrating the software with the AUV. 

D. MISSIONS 

Autonomous vehicles will operate in environments where humans cannot or do 
not wish to go. The Defense Advanced Research Frojects Agency (DARFA) has 
identified over 70 military missions especially suited for AUV execution (Bane and 
Ferguson, 1987), and this simulator incorporates a representative sampling of these 
tasks. The simulator’s mission control software is divided into four main categories: 
charting, reconnaissance, surveillance, and covert payload delivery. 

In each category, the mission controller executes the algorithms required to 
maneuver the AUV to the desired location, perform its required tasks, and return the 
vehicle to its starting position. Additional algorithms handle other tasks or 
emergencies such as path planning, uncharted shallow water, or close contacts. 



27 



Smaller "missions" test the NPS AUV guidance and control systems. These 
tasks, subsets of the larger missions, examine the vehicle’s ability to transit and 
navigate in the test pool. This starts with simple maneuvers such as crossing the 
pool or circumnavigating it, and buUds into more complicated sequences requiring 
the vehicle to execute depth changes, to pass through specific coordinates, and to 
maneuver for collision avoidance. Since the NPS AUV is capable of hovering, 
additional missions will be developed requiring the vehicle to switch between its 
propulsion and hovering systems for collision avoidance or reconnaissance. 

E. CONTROL SYSTEM ARCHITECTURE AND LANGUAGES 

The NPS AUV is controlled by a hierarchical system architecture that divides 
control among three areas: the mission level, the guidance level, and the execution 
level. Each section exchanges data or commands with its adjacent level and is 
responsible for monitoring or executing a specific portion of the AUV’s mission. 

1. The Mission Level 

The mission level is the interface between the human user and the AUV. 
This level, written in the KEE software development shell, presents a menu of 
mission choices for the user’s selection. After a choosing a mission, the user 
provides critical parameters for the AUV to execute. The mission level plans the 
execution of the task and issues the appropriate commands to the guidance level. 
Execution begins after initial path planning has been completed, and the mission 
level supervises the successful completion of the user’s assigned tasks. 
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2. The Guidance Level 



The simulator’s guidance level receives orders from the mission level and 
generates guidance commands for the AUV’s execution level. This software is 
written in Common LISP and is actually a set of modular procedures implemented 
according to the tasks selected by the mission level. One important procedure of 
this level is a global path planner using a best-first search algorithm to plot an 
AUV track which the vehicle follows to avoid charted obstacles. When the vehicle 
begins to transit toward its goal, the guidance level requires additional mission-level 
commands in order to invoke the correct procedures. 

A second important procedure of the guidance level receives sensor inputs 
for processing and interpretation. Sensor data may require the guidance level to 
modify its commands to the execution level to avoid collisions or to take advantage 
of unanticipated mission opportunities. 

3. The Execution Level 

The execution level is written in the C language and is the lowest level of 
simulator control. This level receives guidance commands and executes routines to 
maneuver the AUV to the correct depth, course, and speed. The execution level 
updates the graphics displays (between ten and thirty times per minute) to reflect 
the mission’s current status and passes the AUV’s latest position up to the guidance 
and mission levels. 
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F. SIMULATION FACILITIES 



The AUV simulator runs on a LISP machine and an IRIS graphics workstation. 
Two models of each machine were available for this thesis and were used to 
demonstrate j>erformance variations and code compatibility. 

1. Texas Instruments Explorer II LISP Machine 

The TI Explorer II was chosen to execute the mission and guidance levels 
of simulator control. This machine is an advanced single-user workstation that uses 
the KEE software development shell to support the generation of large-scale and 
complex artificial intelligence programs. The programming environment includes 
very high speed proprietary processors, a large memory, sophisticated caching and 
memory-management systems, high-resolution black-and-white graphics, and 
networking facilities. Tlie KEE shell gives the user a productive and intuitive 
programming environment for developing large and complex applications. (TI 
Explorer II User’s Manual, 1988.) 

2. Symbolics LISP Machine 

The Symbolics 3675 LISP machine is also an artificial-intelligence 
workstation with the KEE software development shell. It has many of the same 
features as the TI LISP machine with additional support for image processing. 
Although the Symbolics LISP machine is slower than the TI, its image-processing 
capability will be incorporated into future research. (Symbolics User’s Manual, 
1987.) 
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3. IRIS 2400T Workstation 



The Silicon Graphics IRIS-2400T graphics workstation is used for the 
original AUV simulator execution level and display. This system is a Unix-based 
high-resolution 1024 x 768 color display processor optimized for graphics 
applications. Its robust and highly efficient capabilities are primarily embedded in 
hardware instead of the more common software implementation. The system’s fast 
execution is supported by an applications/graphics processor, a hardware matrix 
multiplier pipeline (the "Geometry Engine"), and a 32-bitplane raster subsystem. 

This workstation’s specialized capabilities and speed make it particularly suitable for 
real-time displays. (IRIS User’s Guide, 1986.) 

4. IRIS 4D/70GT Workstation 

The newer AUV simulator runs on the IRIS 4D/70GT graphics 
workstation. This machine, a third-generation descendant of the IRIS 2400T, is the 
result of extensive hardware and software design improvements. The new system 
pipeline architecture uses multiple RISC-based CPUs with a high-speed 64-bit data 
bus and a 96-bitplane raster subsystem. In addition to a much faster hardware 
Geometry Engine, the Unix-based software supports a style of object-oriented 
programming that greatly speeds image processing and updating. The system 
readily supports a higher update rate for a real-time AUV simulation while 
simultaneously incorporating graphics lighting and shading models. (IRIS 4D User's 
Guide. 1988.) 
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G. SUMMARY 



This chapter discusses the problems of this thesis in detail and outlines 
proposed solutions. Several AUV models are described and differences in their 
mathematical and dynamic models are contrasted. The AUV simulator missions and 
environments are discussed and the system’s architecture and programming 
languages are explained. Finally, the simulation’s LISP machine and IRIS graphics 
workstation facilities are listed. 
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IV. AUV SIMULATOR DESCRIPTION 



A. INTRODUCTION 

This chapter describes the simulation software. The description starts with an 
explanation of the hierarchical AUV software architecture and how each level of the 
hierarchy carries out its tasks. The mission level of the software is discussed first, 
showing how the user inputs objectives to enable the controller to plan a mission 
and issue commands to the guidance level. Tlie guidance section of this chapter 
explains how mission-level commands are implemented by the guidance level and 
how the results are represented at the execution level. A description of the 
software’s execution level is followed by an explanation of the communications 
code that links all machines and software modules. The last section of this chapter 
is a user’s manual; this manual repeats portions of the MacPherson (1988) manual 
for clarity and continuity. 

B. SOFTWARE ARCHITECTURE 

This thesis has preserved the hierarchical software architecture implemented by 
MacPherson (1988), as can be seen in Figure 4.1. Tlie top level of the AUV 
software architecture is the mission level-- a knowledge base implemented using the 
KEE software development shell. The user interacts directly with this knowledge 
base by selecting a mission and then supplying additional infonnation when 
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Figure 4.1 Hierarchical System Architecture 
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prompted. Once this information has been acquired, the simulator operates 
autonomously to carry out the user’s mission and report its completion. 

The simulator begins by accessing the second level in its hierarchy. The 
mission level starts its planning by passing its parameters down to the path planner 
and navigator. The planner and navigator are guidance-level Common LISP 
software modules which consult the guidance level’s environmental database to 
select a path to the mission’s goal and repon this path back to the mission level. 

Once supplied with the mission parameters and a path to the mission’s goal, 
the guidance level communicates with the hierarchy’s third level-- the execution 
code. Maneuvering parameters are interpreted by the execurion-level autopilot as 
control surface commands that put the simulator’s AUV on the path’s course, speed, 
and depth. The execution level software includes sensor modules that provide 
simulated electronic, acoustic, and visual environmental inputs to the AUV. These 
inputs are passed back up the hierarchy to the navigator and the mission supervisor 
where the data is analyzed and acted on. 

C. THE MISSION LEVEL 

The KEE (Knowledge Engineering Environment) software development shell 
organizes the mission level. This powerful software development tool runs on the 
TI Explorer II or the Symbolics LISP machines and is used to place the simulator’s 
many LISP functions into an easily-accessible structure. Although KEE includes a 
proprietary rule-based language, this simulator uses no rules to set up its relations. 
The structure of this knowledge base graphically links related missions on a tree 
diagram that can be traversed by the user with a mouse; the user makes a selection 
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and is prompted for additional information that is used to plan and execute the 
mission. Additional KEE utilities load the appropriate LISP files, display messages, 
update the knowledge base, and display the mission tree. The missions in this tree 
are created using a template system described in Chapter IV of MacPherson (1988). 

The first NPS AUV missions will test the vehicle’s propulsion and control 
surfaces. Once the mechanical systems operate satisfactorily, more sophisticated 
missions will be implemented to evaluate the AUV’s ability to operate 
autonomously in a variety of situations. One of these missions under development 
is reconnaissance— the AUV will be required to move about the pool, to locate and 
map obstacles for later analysis, and to trail moving objects while recording sensor 
information. 

D. THE GUIDANCE LEVEL 

The guidance level is written in Common LISP and runs on either the TI 
Explorer D or the Symbolics. These software modules, consisting of the mission 
navigator and path planner, receive orders from the mission level and provide 
guidance commands to the execution level. The first order fi'om the mission level 
passes the mission’s start and goal coordinates to the path planner. The path 
planner conducts a best -first search (Barr and Feigenbaum, 1981) to produce a series 
of coordinate subgoals which the vehicle will follow. These subgoals are passed to 
the simulation navigator and the mission’s autonomous execution begins. Using 
frequent data exchanges via the communications interface, the navigator provides the 
execution level with infonnation on the next subgoal, the autopilot 
course/speed/depth, and the command required to execute the current phase of the 
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mission. The communications interface passes back execution-level data on sonar 
contacts, the vehicle’s position, and the depth of water under the AUV’s keel. The 
guidance level processes this data and modifies the mission commands as necessary 
for the next data exchange. 

The guidance level software is actually a number of LISP modules, each 
designed to perform a specific part of a mission. For example, the "transit" module 
contains code that commands the vehicle to move from the mission’s starting 
coordinate to its next subgoal. Tliis module executes from subgoal to subgoal until 
the AUV has reached its final goal. 

E. THE EXECUTION LEVEL 

The execution level is written in C and runs on the IRIS 2400T or the IRIS 
4D/70GT graphics workstation. This level is the lowest level of AUV control; it 
executes either manual or autopilot commands to update vehicle and environmental 
displays. In autopilot mode, the execution level receives guidance-level commands 
for the location of the next mission subgoal, AUV course/speed/depth, and the 
mission phase. The execution level code interprets these commands, positions each 
control surface to achieve the AUV’s parameters, and updates the graphics display 
to show the vehicle’s current orientation. 

At each update, the execution level passes sensor infonnation up to the 
guidance level. Tliis data is processed and can be used to alter the next set of 
guidance commands. An example of this occurs w'hen the AUV’s sensors repon 
"uncharted" shallow water or obstacles (features unknown to the navigator’s 
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environmental database) causing the guidance level to alter its commands, reposition 
the AUV, and prevent a collision. 

1. The Original AUV Graphics Display 

The original AUV display (MacPherson, 1988) is the primary means for a 
user to observe the performance of a vehicle as it executes an open-ocean mission. 
The display contains four sections: an "out the periscope" view of the environment, 
a navigation chart, a sonar screen, and a control panel. This presents the operator 
with a visual perspective from the AUV’s point of reference, a plot showing the 
AUV’s position, course, and goal, a sonar display of the contact situation, and a 
representation of the AUV’s control surface positions. (See Figure 4.2.) 

The upper left portion of the display is the periscope view. The AUV’s 
periscope can be trained in azimuth or in elevation; it shows the vehicle’s 
environment in either low- or liigh-power magnification. Several ships, islands, and 
buoys are included in this enviromnent to provide obstacles for the AUV to avoid. 
When the AUV submerges, this periscope is automatically "lowered" and secured at 
a depth of fifty feet; the periscope is "raised" at fifty feet when the AUV returns to 
the surface. 

The upper right portion shows the AUV’s active sonar display. The 
execution-level code simulates an active sonar pulse transmission; contacts are 
shown on the display as black dots. Two cursors on the sonar display represent the 
vehicle’s course (black) and the bearing on which the periscope is trained (green). 
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Figure 4.2 Original AUV Simulator Control Panel 
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The contact situation is updated every cycle and this information is passed up to the 
guidance control level. 



The display’s lower left portion depicts a navigation chart representing the 
simulator’s environment and the vehicle’s position. During autopilot control, a red 
"X" marks the AUV’s position, the simulator’s "start" and "goal" coordinates are 
outlined with red circles, and a red line shows the AUV’s course. The chart uses 
shades of blue to show different water depths; land is displayed in black. As the 
guidance level executes its mission, the chart updates the AUV’s position and 
displays the autopilot course, speed, and deptlr. 

The display’s center and lower right portions contain control panel 
information. Propulsion status is shown with a "battery charge" gauge to simulate 
the AUV’s power supply; an alarm sounds when the vehicle reaches a low batteiy 
condition. Panels below the battery charge gauge show the AUV’s actual course, 
speed, depth, pitch angle, and control surface positions so that the user can follow 
the vehicle’s reactions to guidance-level commands. 

2. The NFS AUV Graphics Display 

The NPS AUV display has been adapted from a model programmed by 

Schwartz (1988) and is the user’s means to observe the vehicle’s performance 
V 

during small-scale test missions. This simulation display consists of two sections: 
a representation of the AUV in a "test pool" from the perspective of an external 
viewer, and a control panel display showing the vehicle’s and observer’s parameters. 

This graphics display is intended to simulate actual test conditions for the 
NPS AUV and is designed to show a realistic presentation of the vehicle in its 
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environment. The external perspective shows the NPS AUV (approximately five 
feet long) in a test pool (approximately 120 feet by 60 feet by eight feet deep) with 
several cylindrical obstacles. For path-planning purposes, the lower-left comer of 
the pool is the vehicle’s coordinate origin with the piool’s longer dimension on a 
north-south axis. The display allows the user to view the AUV’s orientation and 
control surface positions as it maneuvers inside the test pool. 

The control panel is similar to the original AUV control panel display. In 
addition to vehicle course, speed, depth, and control surface positions, it also gives 
the coordinates of the viewer’s position with respect to the AUV. In manual 
control, the user can "shift position" to observe the vehicle from different 
perspectives as it executes its missions. 

F. COMMUNICATIONS SOFTWARE 

The execution-level code on each IRIS graphics workstation requires 
communications support for data exchanges with the guidance-level code on the 
LISP machine. Both communications modules link a graphics workstation with a 
LISP machine via an Ethernet cable; each module passes the same data typ>es and 
structures in slightly different formats. Tlie user selects the machines on which the 
simulation will be run; this detennines which portions of the communications 
modules wUl be used to support the simulation. 

The original communications code is adapted from MacPherson (1988); this 
thesis did not intend to alter that communications subsystem when the simulation 
was extended from one IRIS workstation to another. However, there is a significant 
difference between the hardware architecture and the operating systems of the two 
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IRIS machines— and initial attempts to port the code were unsuccessful. Another 
thesis (Shannon and Teter, 1989) solved the problem of exchanging simulation data 
between a Symbolics machine and the IRIS 4D/70GT; that code was adapted for the 
NFS AUV simulator. Although additional effort will be able to convert the original 
communications code, its algorithms are not efficient and, as described below, this 
research used a different approach. 

Regardless of the machine-specific algorithms, the information exchange 
between a LISP machine and an IRIS workstation allows the guidance level to send 
commands to control the execution level; the execution level uses the 
communications code to send sensor data back to the LISP machine for analysis. 
This information exchange executes in a loop that occurs about every three seconds. 
After carrying out its initial mission commands, the execution level passes to the 
guidance level a data package containing the AUV’s present course, speed, and 
depth, the depth under the AUV’s keel, and sonar contact bearing/range information. 
The LISP machine analyzes this data and sends back the mission phase command, 
the coordinates of the next subgoal, and the autopilot course, speed, and depth 
required to reach that subgoal. 

This communications code is not critical to the success of the NPS AUV, so 
emphasis was placed on implementing a functional solution instead of a robust, 
efficient subsystem. While both versions of the communications code caused 
considerable problems during simulator implementation, these subsystems will not be 
required for actual AUV operations. The NPS AUV architecture design uses a 



42 



single processor; data is passed between the guidance and execution levels in a 
much quicker and more reliable structure. 

1. The Original Communications Software 

The software for this portion of the simulator is described in Barrow 
(1988) and provides standard routines to support communications between different 
computers connected via Ethernet and the Transmission Control Protocol/lntemet 
Protocol (TCP/IP) systems (Comer, 1988). 

The server portion of this package is written in C and runs on the IRIS 
2400T workstation. The software supports full-duplex communications by sending 
data through one port and receiving data through a second port. These ports are 
linked to TCP/IP sockets and processes are spawned to service each socket. Data is 
exchanged through an IRIS shared-memory segment of one Mbyte to communicate 
between the IRIS execution level and the LISP-machine guidance level. 

The client portion of the package is written in Common LISP and runs on 
either the TI Explorer II or Symbolics LISP machines. These routines maitipulate 
an instantiation of the IP::TCP-HANDLER flavor of the system’s TCP/IP software 
(Symbolics User’s Manual, 1987; TI Explorer II User’s Manual, 1988); two-port 
connections are established with a specific IRIS server to send and receive floating 
point numbers, integers, and characters. 

Wlien either the client or the server transmit data, the information is sent 
via a series of Ethernet packets; each packet contains a single four-byte data 
segment. Each Ethernet packet has a minimum 512-byte length so most of the 
packet is unused. The communications code execution is comparable to the IRIS 
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2400T display update rate so this inefficiency does not inhibit the simulation’s 
execution, but this scheme can be improved to send all data in a single Ethernet 
packet. 

2. The NFS AUV Communications Software 

The original communications software required extensive modifications to 
run on the newer IRIS 4D/70GT workstation. After considerable experimentation, 
these modifications were judged to be beyond the scope of this thesis so another 
approach was investigated. Thesis work by Shannon and Teter (1989) involved 
similar communications code for a simulator application and the server portion of 
that code has been adapted to support the NFS AUV simulator. 

The client code on the LISP machines is largely unchanged, but two 
additional algorithms have been added to read and write the different data format 
that is exchanged with the newer IRIS workstation. The read function parses the 
execution-level data package into its individual components and arranges these 
components in a list for analysis by the guidance -level routines. The write function 
places the guidance-level commands in a formatted message that is transmitted to 
the IRIS machine. 

The server code on the IRIS machine supports semi-duplex 
communications-- two ports are stiU used on the LISP machines but all data is 
transferred through a single port on the IRIS workstation. Data exchange between 
the client and the server is always sequential so this does not affect the execution 
or guidance levels. Since all data is transferred in a single formatted message, tliis 
system makes more efficient use of the Ethernet packet size and the data exchange 
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proceeds at a much faster rate. (The LISP code for the client side of this system is 
shown in the Appendix.) 

G. USER’S MANUAL 

The NPS AUV simulator is menu-driven and prompts the user for input. This 
manual assumes the user has a basic familiarity with the Symbolics and TI Explorer 
n LISP machines as well as both IRIS graphics workstations. Some experience is 
required with the KEE expert system shell and the UNIX operating system in order 
to start up and secure the simulator, but not for its operation. Since this thesis 
works with a variety of machines and implementations, different portions of code 
will have to be loaded and executed depending on the combination of LISP machine 
and IRIS workstation the user desires. Tliis manual also repeats portions of the 
MacPherson (1988) user’s manual for continuity. 

1. Graphics Workstation Operations 
a. The Original AUV- IRIS 2400T 

The IRIS 2400T simulator can be operated in either the manual or 
autopilot mode. To start the simulation, "log on" to the IRIS 2400T side tenninal 
and then transfer to the director)' Iworkltwrdmanl thesis! symbolicsisubsim or 
Iworkinordmanithesisiti-explorerlsubsim. Start the simulator in manual by entering 
the command sub on the side terminal followed by a carriage return. After reading 
the initial display on the main terminal, press any mouse button to begin. Tlie 
AUV simulator starts with the vehicle in manual control at a depth of zero feet, 
speed zero knots, and course North. 
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All manual control of the AUV is efifected with the main terminal 



keyboard and its mouse buttons. To assist with this operating mode, a user’s Help 
display may be toggled over the chart display by pressing the I-key. This display 
lists the various simulator controls that are explained below. 

The AUV mdder is operated with the keyboard left-arrow and right- 
arrow keys. The stemplanes control the vehicle’s pitch angle; the D-key places 
these planes on dive and the S-key places the stemplanes on rise. The bowplanes 
are used to make small changes to the AUV’s depth without a pitch angle; these 
planes are manipulated with the B-key for dive and the C-key for rise. AUV speed 
is raised by the up-arrow key and lowered by the down-arrow key. 

The AUV periscope has a number of features. The scope’s 
magnification power is shifted by using the H-key for high power and the L-key for 
low power. The left mouse button rotates the periscope counterclockwise and the 
right mouse button rotates the scope clockwise. The middle button will raise the 
scope elevation angle while the simultaneous right and left mouse buttons will lower 
the elevation angle. As the AUV is surfaced and submerged, the periscope will 
automatically lower as the vehicle proceeds deeper than fifty feet; the periscope will 
be raised when the vehicle ascends shallower than fifty feet. 

The autopilot is started by pressing the A-key on the main keyboard. 
The side terminal will indicate that the IRIS server is waiting to connect to either 
expl (the T1 Explorer 11) or syml (the Symbolics LISP machine); a message will 
also instruct the user to start the KEE portion of the simulator to connect the LISP 
client with the IRIS server. 
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The autopilot execution can be interrupted by pressing the Q key; this 
will terminate the autopilot but the simulator will return to its manual mode. The 
autopilot cannot be restarted (due to the system’s shared memory constraints) but 
the simulator may be stopped by pushing all three mouse buttons simultaneously. 
Prior to restarting the IRIS-2400T simulator autopilot, ensure the previous socket 
connection has been correctly broken. To do this, list the current processes with the 
Unix command ps -ax and stop any Iwork/nordman... communications daemons with 
the kill command. (Inexperienced users may require assistance for this step.) 
b. The NFS AUV- IRIS 4D/70GT 

The NPS AUV simulator may also be operated in the manual or 
autopilot modes. To start the simulation, "log on" to the side terminal of the IRIS 
4D/70GT and transfer to the directory lusriworki nor dman! thesis! symbolicsiauvsim or 
/usriworkinordmanithesisiti-explorerlauvsim. Start the program in manual by 
entering the command auv on the side terminal followed by a carriage return. 

The simulated AUV starts on the surface at a speed of 25 rpm on 
course East. All manual control in this simulator uses the mouse to manipulate 
markers on the control panel at the right side of the main terminal display. To 
alter the viewer’s perspective or to change AUV parameters, move the mouse arrow 
over the control panel marker for that parameter, press and hold the left mouse 
button, and drag the marker to the desired new value of that parameter. (Changes 
to the viewer's perspective should be executed slowly or the user may lose his own 
perspective in the display.) At very low speeds, the AUV may slowly roll from 
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port to starboard; raising speed will restore control surface effects on the 
mathematical AUV hydrodynamic drag model and should damp out this motion. 

The autopilot is started by pressing the A-key on the main keyboard. 
The side terminal will indicate that the IRIS server is waiting to connect to either 
expl (the TI Explorer II) or syml (the Symbolics LISP machine); a message will 
also instruct the user to start the KEE portion of the simulator to connect the LISP 
client with the IRIS server. 

The autopilot execution can be interrupted by pressing the Q-key; the 
autopilot cannot be restarted at this point but manual control of the AUV is 
available. Prior to restarting the IRIS 4D/70GT simulator autopilot, ensure the 
previous socket connection has been correctly broken. To do this, list the current 
processes with the Unix command ps -al and stop any lusriwork/nordman... 
send/receive communications daemons with the kill command. (Inexperienced users 
may require assistance for this step.) 

2. LISP Machine Operations 
a. TI Explorer II 

The TI Explorer II must be loaded with the KEE expert system 
software shell. (It should be available by entering SYSTEM-K.) If the shell is not 
loaded, a cold boot of the machine will be required; inexperienced users should get 
help at this point. When KEE is available, "log on" in the LISP Listener and then 
press tlie SYSTEM-K combination to move to the KEE desktop. (See Figure 4.3.) 
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Figure 4.3 KEE Desktop with a Proposed Reconnaissance Mission 
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Use the mouse to point at the KEE latchkey icon at the screen’s upper left comer 
and push tlie left mouse button. 

A pop-up menu will ^>pear offering KEE Commands-, select the Load 
KB command by pointing at the command with the mouse and pushing the left 
mouse button. A KEE "typescript window" will appear requesting the name of the 
knowledge base to be loaded; enter exp3 :nordman;auv.u followed by a carriage 
return. KEE will load the AUV knowledge base and then will load the LISP code 
files containing the guidance level functions. (The loading process will take about 
ten seconds.) Once the files are loaded, use the mouse to point to the word AUV 
in the knowledge base window and press the left mouse button. Another pop-up 
menu wUl offer KB Commands', use the left mouse button to select the Display 
option. The AUV Simulator Mission Tree will be drawn in a window labelled The 
Graph of the AUV Knowledge Base. 

Select an AUV mission by using the mouse to point to the desired 
generic mission at one of the leaves of the Mission Selection Tree. Press the left 
mouse button to choose the mission; a pop-up menu of Unit Commands will appear. 
Point at the Send Message option with the mouse and push the left mouse button 
again; a pop-up menu of Message Types will appear. Point the mouse to the 
message that starts the desired mission and press the left mouse button a final time. 

The AUV simulator mission-level code will ask the user several 
questions about mission parameters. These questions will appear in the KEE 
typescript window and should be answered by entering answers to each of these 
questions followed by a carriage return. When the KEE typescript window 
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announces that it has connected with the appropriate IRIS workstation, move to that 
workstation and press a carriage return on the side terminal. The IRIS side terminal 
will notify the user that it has sent initial parameters to the LISP machine and the 
mission-level code will begin a best-first search to determine the AUV’s path. 

When the KEE typescript window displays the message autopilot course on first leg 
is:, press another carriage return on the IRIS side terminal to begin autonomous 
simulator execution. 

If necessary, the AUV simulator can be stopped by entering 
CONTROL-ABORT. This will complicate the orderly shutdown of the TI Explorer 
n communications sockets and should be avoided. Once the simulator has 
completed its mission, return to the LISP Listener and enter the command (end-con) 
to break the TI-IRIS socket coruiection. Tlie simulation may be restarted by re- 
entering the appropriate commands to start another mission from the KEE Mission 
Tree. 

b. Symbolics 

On the Symbolics LISP machine, ensure the KEE expert system 
shell software is loaded. (It is accessed by entering SELECT-K.) If the shell is 
not loaded, a cold boot of the machine will be required; an inexperienced user 
should get staff assistance at this point. Once KEE is available, "log on" in the 
LISP Listener and then press the SELECT-K key combination to move to the KEE 
desktop. (See Figure 4.3 on page 49.) Use the mouse to point at the KEE 
latclikey icon at the screen’s upper left comer and push the left mouse button. A 
pop-up menu wUl appear offering KEE Commands', select the Load KB command 
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by pointing at the command with tlie mouse and pushing the left mouse button. A 
KEE "typescript window" will appear requesting the name of the knowledge base to 
be loaded; enter sym4:>nordman>auv.u followed by a carriage return. KEE will 
load the AUV knowledge base and then will load the LISP code files containing the 
guidance-level functions. (This process will take approximately thirty seconds.) 

Once the files have completed loading, use the mouse to point to the word AUV in 
the knowledge base window and press the left mouse button. Another pop-up menu 
will offer KB Commands', use the left mouse button to select the Display option. 

The AUV Simulator Mission Tree will be drawn in a window labelled The Graph of 
the AUV Kfiowledge Base. 

Prior to selecting a mission, an IRIS terminal must be chosen for the 
simulation. Ensure that either the IRIS 2400T or the IRIS 4D/70GT has been 
placed in its autopUot mode and is waiting to connect to the Symbolics LISP 
machine (s}’ml). On the Symbolics machine, return to the LISP Listener window 
(SELECT-L, not the KEE LISP Listener) and select the appropriate IRIS 
workstation by entering the commands (choose-iris ’irisl) (for the IRIS 2400T) or 
(choose-iris ’iris5) (for the IRIS 4D/70GT). This will start the TCP/IP software on 
the LISP machine and locate the correct IRIS port(s) for data exchange. The user 
should then return to the KEE environment by entering SELECT-K. 

Back in the KEE shell, select a mission by using the mouse to point 
to the desired generic mission at one of the leaves of the Mission Selection Tree. 
Press the left mouse button to choose the mission; a pop-up menu of Unit 
Commands will appear. Point at the Send Message option with the mouse and push 
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the left mouse button again; a pop-up menu of Message Types will appear. Point 
the mouse to the message that starts the desired mission and press the left mouse 
button a final time. 

The AUV simulator mission-level code will ask the user several 
questions about mission parameters. These questions will appear in the KEE 
typescript window and should be answered in that window by first selecting the 
window with the mouse and then entering answers to each of these questions 
followed by a carriage return. When the KEE typescript window announces that it 
has connected with the appropriate IRIS workstation, move to that workstation and 
press a carriage return on the side temtinal. The IRIS side terminal will notify the 
user that it has sent initial parameters to the LISP machine and the mission-level 
code on the LISP machine will begin a best-first search to determine the mission’s 
path. When the KEE typescript window displays the message autopilot course on 
the first leg is:, press another carriage return on the IRIS side terminal to begin 
autonomous simulator execution. 

If necessary, the AUV simulator can be stopped by entering 
CONTROL-ABORT. This will complicate the orderly shutdown of the Symbolics 
communications sockets and should be avoided. Once the simulator has completed 
its mission, return to tire LISP Listener and enter the command (end-con) to break 
the Symbolics-IRIS socket connection. The simulation may be restarted by securing 
and restarting an IRIS simulator, re-entering the appropriate LISP machine command 
to choose an IRIS workstation, and then starting another mission from the KEE 
Mission Tree. 
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H. SUMMARY 



This chapter describes the simulator’s operation. The first section starts with 
an overview of mission execution and then stresses tlie specific workings of the 
software architecture hierarchy. Subsequent sections provide detailed discussions of 
the mission, guidance, and execution levels of this hierarchy for two typ>es of IRIS 
graphics workstations. One section describes both types of communications software 
used in this thesis, explains the reasons for their use, and discusses their differences. 
The final section of this chapter contains the User’s Manual to assist in operating 
different combinations of the four machines. 
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V. EXPERIMENTAL RESULTS 



A. INTRODUCTION 

This chapter evaluates the experimental results of the AUV software 
conversion and examines sample runs on the simulator’s various combinations of 
machines. 

B. AUV SIMULATION FACILITIES 

1. The Original Simulator 

The original AUV graphics simulation (on the IRIS 2400T) now runs 
under either the Symbolics or the TI Explorer II LISP machines. The TI Explorer 
n is the faster machine (by roughly 50%) but manufacturer’s updates to its 
operating system have historically caused problems with the simulator’s 
communications code port requests. The Symbolics machine is a reliable backup to 
the TI Explorer II. 

2. The NPS AUV Simulator 

The NPS AUV simulator (on the IRIS 4D/70GT) now runs under 
autopilot control from either the Symbolics or TI Explorer II LISP machines. The 
guidance-level LISP code still performs as described in MacPherson (1988) but the 
execution-level output is now displayed from an external j>erspective and in a more 
realistic simulation. 
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Several revisions to the execution-level code improve the simulator’s 
realism. The NPS AUV program was optimized to run on the faster IRIS 4D/GT70 
workstation and its algorithms take advantage of the machine’s processing capability 
and greater speed. This is clearly demonstrated in the simulation’s graphics, where 
lighting and shading models give the AUV and its environment a depth perspective 
that is not evident in the "flat" graphics display of the IRIS 2400T. While the 
earlier simulator rotates the environmental scene about the viewer, this simulator 
allows the viewer to "move about" the display and to examine it from a nearly 
unlimited variety of angles, distances, and elevations. Although this type of display 
requires much more computer processing, the IRIS 4D/70GT manipulates its 
perspectives faster than the IRIS 2400T can run its simpler simulation. 

Tlie user interface for the NPS AUV simulator is easier to understand and 
simpler to operate. The IRIS 2400T program accepts input through twenty different 
keys and mouse buttons (and uses a help menu to assist the user), but the IRIS 
4D/GT70 display is completely mouse-driven with one button. While the older 
vehicle requires continuous user input to reach its desired parameters, the newer 
simulation immediately accepts and displays the user’s commands and tiien applies 
them to the hydrodynamic equations. The user is free to examine the vehicle’s 
response without having to provide additional input. 

The NPS AUV program allows the user a greater flexibility in starting and 
observing a mission; it also permits more missions to be run in the same amount of 
time. While the older simulation starts each mission from the same location, the 
NPS AUV simulator allows the user to start from any depth or position in the test 



56 



pool. Instead of observing the older AUV missions on a two-dimensional plot, the 
newer simulator allows the user to choose an initial viewing position before 
beginning the mission. This useful feature permits observation from a number of 
perspectives to examine control surfaces, thruster operation, or restricted 
maneuvering. The user is able to conveniently and quickly examine the AUV’s 
simulated operation in exactly the same way as the actual vehicle will be observed. 
This not only exceeds the capabilities of the older simulator but also can produce 
reduced testing requirements for the actual NPS AUV. 

The NPS AUV simulator autopilot uses the same methods as the older 
simulator to initialize its missions. After selecting the viewer perspective and the 
vehicle’s initial position, the user inputs the same mission parameters as required by 
the original simulation. Although the NPS AUV is operating in a smaller 
environment, the vehicle still has a significant number of obstacles to avoid when 
conducting path-planning. The best-first path-planning algoritlun operates 
satisfactorily (and identically) in either environment to guide the vehicles around 
obstacles and reach a goal. Its test -pool transit is shorter, but the NPS AUV can 
encounter more obstacles than tlie older vehicle, so the path-planner generates more 
complicated routes with a number of abrupt maneuvers to reach the vehicle's goal. 
Once the mission’s execution is started, the vehicle maneuvers to reach its goal 
while the viewer watches from a chosen perspective. The side tenninals of both 
graphics workstations also display infonnation on vehicle paiameters and 
environmental conditions. 
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The NFS AUV simulator has been explicitly designed to test a variety of 
AUV models in a selection of environments. Significant software design effort was 
devoted to implementing a modular code structure that will allow the rapid addition 
of new features. Proficient programmers can alter the location of obstacles, add 
moving contacts, change the AUV’s maneuvering characteristics, and test different 
types of controllers all by adding or replacing modules of simulator code. 

The NPS AUV simulator presently runs much simpler missions than the earlier 
simulation. Although the test pool is filled with obstacles, there are no 
maneuvering contacts for the NPS AUV to track and avoid. The transit and 
reconnaissance missions are subsets of the original program’s more complicated 
open-ocean missions, but these missions are being expanded to incorporate contact 
avoidance, dynamic path-replanning, switcliing between hovering and propulsion, and 
using sonar for environmental mapping. As different system designs and algoritluns 
are developed for successive NPS AUV models, their performance can examined by 
adding those features into the test pool missions. 

3. Communication Between IRIS and LISP Machines 

The inter-computer communications code developed by Barrow (1988) is 
designed to run under the AT&T Unix System V implementation and was originally 
developed for the IRIS 2400T and IRIS 4D workstations. (The IRIS 4D is an 
earlier version of the IRIS 4D/70GT.) After several lengthy and unsuccessful 
attempts to port the Barrow code to the IRIS 4D/70GT, the Shannon and Teter 
(1989) communications code was substituted for die BaiTow client/server system. 
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Nearly all of the Unix System V routines on the IRIS 4D/70GT appear 
to be compatible with earlier implementations; most of the code conversion only 
required updating library subroutine definitions. However, the IRIX operating 
system (IRIS 4D User’s Guide, 1988) handles sha.'’ed-memory opterations in a 
different manner than the earlier IRIS 4D systems and it is unclear whether the 
Barrow shared-memory routines can be adapted to the IRIS 4D/70GT. Time 
constraints halted work on this code conversion; the Shannon and Teter routines 
were substituted. 

A second (and more serious) set of problems arose after the operating 
system on the TI Explorer II was updated. The client communications code on 
either LISP machine obtains a socket port number before connecting with an IRIS 
workstation, but the newer version (4.1) of the Explorer II’s oj?erating system does 
not execute diat port-number request— the code would not even compile or load. A 
lengthy and complicated debugging procedure was unable to isolate and correct the 
problem, and the code was even re-written to use different communications 
protocols. Due to time constraints, this problem was finally avoided by porting tine 
TI Explorer II communications code to the Symbolics LISP machine. Copies of the 
code and its error messages were sent to Texas Instruments for technical assistance, 
where it was determined the failure was due to an opnerating system deficiency (TI, 
1989). An updated Explorer II operating system (version 4.2) has been obtained 
and the communications code will be adapted to this new implementation. 
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C. NPS AUV SIMULATOR OPERATION 



The guidance-level routines develop>ed by MacPherson (1988) are used to build 
the missions executed by the NPS AUV. These modular routines allow the user to 
design more complex AUV missions by simply adding specific tasks to the mission- 
level code. An evolving example of this is the NPS AUV reconnaissance mission. 

The first version of the reconnaissance mission only required the AUV to 
perform a surface transit between two points. After satisfactory performance was 
demonstrated, this was modified to require a submerged transit along a specified 
path with the vehicle returning to its starting point upon completion. The current 
reconnaissance mission requires the AUV to perform a submerged transit to its goal, 
surface to simulate a photographic and electronic sweep of the environment, 
submerge to return to its starting point, and surface for pickup. 

The NPS AUV simulator shows that the vehicle can accomplish a simple test- 
pool reconnaissance mission with the same performance as the original vehicle in its 
open-ocean reconnaissance, and the simulator’s missions can easily be modified to 
execute more complex requirements. 

D. SUMMARY 

This chapter presents a summary of the NPS AUV simulator and its facilities. 
The capabilities of the two LISP machines are contrasted, the simulator’s 
communications code is discussed, and the performance of the AUV mission-control 
routines is evaluated when the simulation uses the more powerful IRIS 4D/70GT 
graphics workstation. 
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VI. SUMMARY AND CONCLUSIONS 



A. RESEARCH CONTRIBUTIONS 

The NFS AUV simulator is an important tool for incorporating new 
autonomous control concepts and algorithms into the latest version of the NFS 
AUV. The KEE expert system shell provides an inexperienced user with an 
intuitive menu-driven system that allows rapid mission planning and execution. Tlie 
shell also provides a powerful environment where programmers can modify the 
simulator’s mission-level code and develop additional missions. The faster and more 
powerful IRIS 4D/70GT graphics workstation effectively simulates the AUV’s actual 
op>eration with a real-time display of the vehicle’s actions, and this workstation hcis 
the capacity to accommodate more complex AUV models or controllers. The 
vehicle simulations have been improved and modified to run on two different LISF 
machines or graphics workstations. 

The simulator is a valuable test and debugging environment that will save 
countless hours of experimentation; it will also verif}' code reliability before the 
software is installed in the actual NFS AUV computer system. The new NFS AUV 
simulator provides the user with a wide choice of starting locations and viewing 
positions to thoroughly examine vehicle performance from many different 
perspectives. This viewing flexibility greatly reduces the risks, simplifies the 
logistics, and minimizes the costs of testing the NFS AUV in its ocean environment. 
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Although it was not intended to be a goal of the simulator research, a better 
communications system is available (Shannon and Teter, 1989) and has been 
adapted to this simulator. The system is faster and more efficient but it is invoked 
at a lower level of abstraction; it will be more difHcult to modify when the 
simulator is updated to pass additional sensor data to the guidance level of control. 
While this simulator was developed as a research project, it is designed to be used 
as a tool. This means that a simple, easily-modified communications system is 
potentially more useful than a faster system with a more complex interface. The 
communications support of distributed simulation systems is vitally important for the 
rapid design and modification of these simulators; a more thorough discussion of 
this issue is presented in Barrow (1988). 

B. RESEARCH EXTENSIONS 

Several research extensions are discussed in MacPherson (1988) and should 
still be applied to this simulator. This includes a faster and more sophisticated 
path-planning algorithm, an AUV vision system for mapping and for contact 
classification, algorithms for inertial or terrain-following navigation systems, and an 
environment for examining the performance of high-resolution sonar systems. 

This simulator must evolve along with the NPS AUV. The NFS AUV design 
team is developing more sophisticated AUV models and controllers as weU as the 
hydrodynamic data to describe the performance of these vehicles. The simulator 
must incorporate the results of that research to present an accurate display of the 
latest AUV’s hydrodynamic and maneuvering characteristics. A highly realistic 
simulation will produce valuable and timely feedback by quickly demonstrating the 
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potential problems or side effects generated by the design team’s efforts. Specific 
examples of these modifications are the hydrodynamic data from the NPS Model 2 
AUV, a "sliding-mode controller" for the NPS AUV’s maneuvering system, and 
guidance-level software to control the vehicle’s transition between propulsion and 
hovering modes. 

An effective AUV must possess adaptability and the ability to replan its 
mission as a result of unexp>ected events. All missions in this simulator are still 
relatively simple and complex missions will require a more complex planner. For 
example, if the vehicle detects an obstacle or an "interesting" contact while 
executing an unrelated mission, it may have to interrupt its primary mission, switch 
to its hovering control mode, and investigate that object. The code required to 
implement the "interrupt" and "hover" decisions will require a rule-based expert 
system; this system can be constructed by supplementing the LISP routines with 
Prolog rules or with the rule-based features of an expert systems shell. 

This simulator’s modular design allows additional vehicle features to be 
quickly incorporated into the graphics display. This will provide a realistic 
demonstration of the performance of new AUV models and controllers and it will 
allow several different models to be compared in a laboratory environment. As the 
sophistication and variety of these models increases, the simulator’s organization 
must also be updated to maintain a simple and user-friendly interface. This can be 
done by using menu-driven options to allow the user to select vehicle models and 
control characteristics before staning the simulation. 
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APPENDIX 



This appendix lists the client-side LISP communications code of the NPS AUV. 



;;; Mode: LISP; Syntax: Common-lisp; Package: USER -*- 

;;; This is the program SYM-IRIS-COMM.LISP. It provides the necessary 
;;; software on the Symbolics LISP machitie to communicate with the IRIS 
;;; 2400T or the IRIS 4D/70GT. It is loaded in the KEE shell with the 

;;; knowledge base AUV.U. 



"Talk" is an object to send and to receive data across a network, 
usage : (send talk :init-destination-host ’iris2) ; get remote host object 



(defvar talk) 



; library functions to be used by flavor conversation-with-iris. 



(defmacro loopfor (var init test expl) 

‘(prog 0 

(setq ,var ,init) 
tag 

,expl 

(setq ,var (1+ ,var)) 

(if (= ,var ,test) (return t) (go tag)))) 



(send talk ;start-iris) 



; make connection 
; send data 

; get data from remote host 
; close communication 
; open closed communication 
; switch from IRIS2 full-duplex 
; comms to 1R1S5 semi-duplex 



(send talk :put-iris data) 



(send talk :get-iris) 
(send talk :stop-iris) 
(send talk :reuse-iiis) 



(send talk :change-iris-ports) 
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(defun convert-number-to-string (n) 

(princ-to-string n)) 

(defun convert-string -to-integer (str &optional (radix 10)) 

(do ((j 0 (+ j 1)) 

(n 0 (-1- (* n radix) (digit-char-p (char str j) radix)))) 

((= j (length str)) n))) 

(defun find-peiiod-index (str) 

(catch ’exit 

(dotimes (x (length str) nil) 

(if (equal (char str x) (char 0)) 

(tlurow ’exit x))))) 

(defun get-leftside-of-real (str &optional (radix 10)) 

(do ((j 0 (l-i- j)) 

(n 0 (+ (* n radix) (digit-char-p (char str j) radix)))) 

((or (null (digit-char-p (char str j) radix)) (= j (length str))) n))) 

(defun get-rightside-of-real (str &optional (radix 10)) 

(do ((index (1+ (find-period-index str)) (1-t- index)) 

(factor 0.10 (* factor 0.10)) 

(n 0.0 (+ n (* factor (digit-char-p (char str index) radix))))) 

((= index (length str)) n ))) 

(defiin convert-string-to-real (str &optional (radix 10)) 

{+ (float (get-leftside-of-real str radix)) (get-rightside-of-real str radix))) 



Port number definitions: IRIS 2 uses full duplex comms so ports are set up for 
this default. 1RIS5 uses semiduplex comms (the same port for send and 
receive) and will have both ports set to *remote-portl*. 



(defvar *remote-portl * 1027) 
(defvar *remote-port2* 1026) 
(def\'ar *local-taUc-port* 1500) 
(defvar *local-listen-port* 1501) 



; this is the remote send port 
; this is the remote receive port 
; this is the local send port 
; this is the local receive port 



Conversation-with-iris flavor definition. 



This definition is not restricted to IRIS, but it can be 
used with any host as long as the remote host does not 
already use ports 1027 or 1026 for its own purposes. 



(defflavor conversation-with-iris ((talking-port-number *remote-portl*) 

(listening-port-number *rcmote-port2*) 
(local-talk-port-number *local-talk-port*) 
(local-listen-port-number *local-listen-port*) 
(talking-stream) 

(listening-stream) 

(destination-host-object) 

) 

0 

rinitable-instance-variables) 

(defmethod (:init-destination-host conversation-with-iris) 

(name-of-host) 

(setf destination-host-object (net:parse-host name-of-host))) 



(defmethod (:change-iris-ports conversation-with-iris) 

0 

(setf talking-port-number *remote-portl*) 

(setf listening-port-number *remote-portl*)) 



(defmethod (:start-iris conversation-with-iris) 

0 

(setf talking-stream 

(tcp:open-tcp-stream destination-host-object 
talking-port-number 
local-talk-port-number)) 

(setf listening-stream 

(tcp:open-tcp-stream destination-host-object 
listening-port-number 
local-Usten-poit-number)) 

(terpri) 

(princ "A conversation with the IRIS machine has been established.") 

(terpri)) 

(defmethod (:reuse-iris conversation-with-iris) 

0 

(send self ;start-iris)) 
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(defun read-string (stream num-chars) 

(let ((out-string "")) 

(dotimes (i num-chars) 

(setf out-string (string-append out-string (read-char stream)))) 
out-string)) 



(definethod (:get-iris conversation-with-iris) 

0 

(let* ((typebuffer " ") 

(lengthbuffer " ") 

(buffer •’ ") 

(buffer-length 1)) 

(progn 

(setf typebuffer 

(read-string listening -stream 1)) 

(setf lengthbuffer 

(read-string listening-stream 4)) 

(setf buffer-length 

(convert-string-to-integer lengthbuffer)) 
(setf buffer 

(read-string listening-stream buffer-length)) 



(cond ((equal typebuffer "1") (convert-string-to-integer buffer)) 
((equal typebuffer "R") (convert-string-to-real buffer)) 
((equal typebuffer "C") buffer) 

(t nU))))) 



(defvar *step-var* 0) 



(defun my-write-string(string stream) 

(let* ((num-chars (length string))) 
(dotimes (i num-chars) 

(write-char (aref string i) stream)))) 
(defmethod (:put-iris conversation-with-iris) 
(object ) 
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(let* ((buffer (cond 

((equal (type-of object) ’bignum) (convert-number-to-string object)) 
((equal (type-of object) ’fixnum) (convert-number-to-string object)) 
((equal (type-of object) ’single-float) (convert-number-to-string object)) 
((equal (type-of object) ’string) object) 

(t "error"))) 

(buffer-length (length buffer)) 

(typebuffer (cond ((equal (type-of object) ’bignum) "I”) 

((equal (type-of object) ’fixnum) "I") 

((equal (type-of object) ’single-float) "R") 

((equal (type-of object) ’string) "C") 

(t "C"))) 

(lengthbuffer (convert-number-to-string buffer-lengtli))) 



(progn 

(my-write-string typebuffer taUcing-stream) 
(send talking-stream : force-output) 



(if (= (length lengthbuffer) 4) 

(write-string lengthbuffer talking-stream) 

(progn 

(loopfor *step-var* (length lengthbuffer) 4 
(write-string "0" talking-stream)) 

(my-write-string lengthbuffer talking-stream) 

)) 

(send talking-stream :force-output) 



(my-write-string buffer talking-stream) 

(send talking-stream : force-output) 

))) 

(deftnethod (:check-iris conversation-with-iris) (size-io) 
(let* ((typebuffer) 

) 

(progn 

(setf typebuffer 

(read-string listening-stream size-io))))) 
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(defrnethod (:stop-iris conversation-with-iris) 

0 

(progn (send listening-stream xlose) 

(send talking-stream xlose)) 

(terpri) 

(princ "A conversation with the DUS machine has been closed.") 
(terpri)) 



(self talk (make-instance ’conversation-with-iris)) 



(defun choose-iris (host-name) 

(cond 

((equal host-name ’iris2) 

(send talk :init-destination-host host-name) ;use iris2 as default output, 
(terpri) 

(princ "IRIS2 selected.") 

(terpri)) 

((equal host-name ’iris5) 

(send talk xhange-iris-ports) ;select semi-duplex comm ports, 

(send talk :init-destination-host host-name) 

(terpri) 

(princ "IRIS5 selected.") 

(terpri)))) 



(defun start-con() 

(send talk :start-iris)) 

(defun get_data() 

(send talk :get-iris)) 

(defun send_float(singIe-float) 
(send talk ;put-iris single-float)) 

(defun send_string(string) 

(send talk :put-iris string)) 

(defun end-con() 

(send talk : stop-iris)) 

(defun restartO 
(send talk :reuse-iris)) 
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